✨ Fiche d'Aide à la Décision

FAD

-

DOCUMENT D’ANALYSE FONCTIONNEL

-

FUNCTIONAL ANALYSIS DOCUMENT

Processus Achat

Microsoft Business Central

• 1. ANAL

Sommaire

1. Introduction 3

2. Vue d‘ensemble 4

3. Planification 5

4. Traitement d‘une livraison directe 6

5. Saisie d’une demande de prix 7

6. Saisie d’une commande cadre 8

7. Saisie d’une commande d‘achat 10

8. Saisie d’un retour d’une commande achat 12

9. Rapports achat 13

10. Historique achat 14

11. Annexe 1 : Liste d‘écarts 16

1. Introduction

Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :

• Visiter les sites clients comme les usines, entrepôts et/ou bureaux
• Conduire des ateliers orientés processus.
• Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
• Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
• Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
• Identifier les volumes des référentiels et données transactionnelles
• Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
• Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.

Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :

Versions du document

Liste de diffusion

1. Vue d‘ensemble
   1. Schéma d’ensemble des processus achat

Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :

3 Planification

3.1. Contexte et Hypothèses

**3.1. Contexte et Hypothèses**

Le processus d'achat au sein d'Almatech est complexe et varie en fonction des besoins des projets. Les achats sont classés en trois types : offres, projets et achats génériques société. Les achats mutualisés multi-projet sont également possibles.

Les deux options pour les achats sont "industrielle" et "spécifique". L'option "industrielle" nécessite un stock minimum, tandis que l'option "spécifique" permet d'anticiper ou de constater les besoins de chaque projet. L'option "spécifique optimisée" combine la conception détaillée avec l'utilisation de pièces standard et la consommation des pièces standard du stock.

La réception des pièces est un processus à revoir, notamment pour savoir où se trouve le colis. Le processus de "incoming" consiste en un contrôle et une réception de la livraison, avec photos du colis non ouvert et ouvert. Les instructions d'"incoming" sont données par le chef de projet.

Les petites commandes nécessitent une chaîne d'approbation, qui peut être dépendante de la personne qui passe la commande ou du risque sur la commande. Les critères d'approbation peuvent inclure l'achat dans le budget ou non.

En ce qui concerne les fonctionnalités souhaitées dans le système, il est demandé un suivi de la confirmation de commande fournisseur, une date de livraison renseignée dans le système, une intégration des coûts de transport lié à la commande et une discussion avec la comptabilité concernant la gestion des frais de transport.

La réception des pièces est actuellement un processus manuel, sans visibilité sur le statut de livraison. Il n'y a pas d'inspection systématique à la réception, et chaque colis reçu est pris en photo. Lorsqu'un colis arrive, il n'est pas toujours clair à qui il est destiné.

Les hypothèses retenues pour ce projet sont les suivantes :

* La mise en place d'un flux d'approbation formalisé pour les achats.
* L'utilisation d'un système de gestion de stock pour suivre les pièces reçues et les pièces en stock.
* La création d'un référentiel fournisseur pour suivre les lead times et les différents plannings.
* L'utilisation d'un système de gestion de projet pour suivre les lignes budget et les dates de planification.

[INFORMATION MANQUANTE]

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

3.2. Schéma des processus ERP : Planification 1.0

3.3. Principales règles de gestion

Dans le processus de planification, le client applique les règles de gestion suivantes :

- Le Chef de Projet (CP) donne l'instruction de faire un contrôle qualité léger ou approfondi.
- Lorsqu'un Incoterm est renseigné, la ville doit être précisée.
- La création d'un document de contrôle qualité est possible.
- Lorsque le responsable qualité valide, la réception est validée.
- Possibilité de réceptionner sans contrôle qualité immédiat, puis de réaliser le contrôle plus tard au niveau des séries/lots.

Le système Microsoft Dynamics 365 Business Central peut prendre en charge ces règles de gestion en utilisant les objets suivants :

- La fiche article pour gérer les informations relatives aux articles.
- Le journal des achats pour suivre les achats et les livraisons.
- Le workflow validation pour automatiser les validations et les contrôles qualité.

Le système peut également être paramétré pour gérer les certificats de qualité et les informations relatives aux livraisons, y compris les livraisons partielles. De plus, il est possible de créer un document de contrôle qualité qui résume les choses à contrôler et demande des photos ou des numéros de lot ou série si nécessaire.

Enfin, le système peut être configuré pour permettre la réception sans contrôle qualité immédiat, puis de réaliser le contrôle plus tard au niveau des séries/lots.

3.4. Documents et statistiques

Création de documents et gestion de statistiques.

Le processus de planification nécessite la création de documents pertinents pour suivre les activités et les performances de l'entreprise. Dans ce contexte, il est essentiel de gérer les documents et les statistiques de manière efficace.

L'atelier scanne les documents avec la pièce pour assurer la traçabilité à la réception. Ces documents sont ensuite utilisés pour créer un document de contrôle qualité. Il existe plusieurs types de documents d'inspection :

- Un document par série : ce type de document est créé pour chaque série de produits.
- Un document par lot : ce type de document est créé pour chaque lot de produits.
- Un document par commande : si il n'y a pas de série ou de lot, un document par commande est créé.

Ces documents sont importants pour suivre la qualité des produits et pour identifier les problèmes potentiels. Il est donc crucial de les gérer de manière efficace.

Pour gérer ces documents, il est possible d'utiliser les fonctionnalités de Microsoft Dynamics 365 Business Central, telles que :

- La création de fiches articles pour chaque produit.
- La gestion des commandes et des livraisons.
- La création de documents de contrôle qualité pour chaque série, lot ou commande.
- La gestion des statistiques pour suivre les performances de l'entreprise.

Il est également possible d'utiliser SharePoint pour gérer les documents et les spécifications de produits. Cela permettra de centraliser les informations et de les rendre accessibles à tous les utilisateurs.

Enfin, il est important de noter que la création d'un document par n° de série et éventuellement plusieurs séries est possible. Cependant, il est nécessaire de définir les règles de création de ces documents pour éviter les doublons et les erreurs.

3.5. Volume des données

Planifiez les lignes projet avec les informations suivantes :

Pour planifier les lignes projet, vous devez renseigner les champs suivants :

- Numéro de projet : spécifiez le numéro de projet associé à chaque ligne pour permettre la consommation sur le projet.
- Tâches projet : renseignez les tâches projet correspondantes pour chaque ligne.
- Lignes budget : configurez les lignes budget pour remonter les coûts budgétés ou les montants réels dans les commandes.

Lors de la saisie des lignes projet, assurez-vous de spécifier les dates de planification pour chaque ligne. Cela vous permettra de suivre l'avancement des projets et de prendre des décisions éclairées.

Pour automatiser et faciliter la planification, vous pouvez utiliser les fonctionnalités de Microsoft Dynamics 365 Business Central, telles que les workflows de validation pour vérifier les informations saisies et les garantir cohérentes.

Il est important de noter que pour une planification efficace, il est essentiel de maintenir à jour les informations sur les lignes projet, notamment les dates de planification et les informations budgétaires.

3.6. Écarts critiques et interfaces

Identifier les écarts critiques entre le processus actuel de planification et les bonnes pratiques du projet.

- Écart critique 1 : La détection des écarts critiques est conditionnée au seuil défini par la personne qui passe la commande ou au risque associé. Ce seuil n'est pas explicitement mentionné, [INFORMATION MANQUANTE].
- Écart critique 2 : La gestion des statuts pour bloquer la facture en comptabilité si la qualité n'est pas validée n'est pas explicitement décrite dans les notes sources. Cependant, cela pourrait être lié à la gestion des statuts dans le journal des achats ou à la validation de la qualité dans un workflow validation.
- Interface nécessaire : Il est possible que la planification nécessite l'intégration avec d'autres applications ou services, tels que la gestion des stocks ou la planification de production. Cependant, aucune information précise n'est disponible dans les notes sources pour confirmer cela.
- Interface nécessaire : Il est également possible que la planification nécessite l'interaction avec d'autres départements, tels que la logistique ou la vente. Cependant, aucune information précise n'est disponible dans les notes sources pour confirmer cela.
- Écart critique 3 : La possibilité de bloquer les livraisons en fonction des informations de lot n'est pas explicitement décrite dans les notes sources. Cependant, cela pourrait être lié à la gestion des lots dans la fiche article ou à la validation des livraisons dans un workflow validation.

En résumé, les écarts critiques et les interfaces nécessaires entre le système cible et les autres applications, services ou départements impactés ne sont pas explicitement décrits dans les notes sources. Il est donc nécessaire de recueillir plus d'informations pour identifier les écarts critiques et les interfaces nécessaires.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

4 Traitement d‘une livraison directe

4.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0

4.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

4.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

4.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

4.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

1. Saisie d’une demande de prix

5.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

• 1. Schéma des processus ERP : Demande de prix 3.0

5.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

5.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

5.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

5.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

6 Saisie d’une commande cadre

6.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0

6.3. Schéma des processus ERP : Saisie d’une commande d’achat

6.4. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

6.5. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

6.6. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

6.7. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

7 Saisie d’une commande d‘achat

7.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

7.2 Schéma des processus ERP : Saisie d’une commande d’achat

7.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

7.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

7.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

7.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

8 Saisie d’un retour d’une commande achat

8.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0

8.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

8.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

8.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

8.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

9 Rapports achat

9.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

9.2 Schéma des processus ERP : Rapport achat 8.0

9.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

9.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

9.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

9.6. Ecarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

10 Historique achat

10.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

10.2 Schéma des processus ERP : Historique achat 9.0

10.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

10.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

10.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

10.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

11 Annexe 1 : Liste d‘écarts

11.1. Liste d’écarts

La liste d’écart doit être initialisée et finalisée à la fin de la phase d’analyse.

Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).